[PWGJE] Add SlimTables data model and producer for future standalone embedding studies by louisemillot · Pull Request #15132 · AliceO2Group/O2Physics

louisemillot · 2026-02-23T22:07:06Z

This PR introduces a new slimmed data model together with a dedicated producer workflow in PWGJE. The objective is to provide a reduced set of AOD tables containing only the minimal information needed for standalone embedding studies and derived AO2D production
These derived datasets are intended to be used as reduced inputs for further jet substructure analyses, including studies based on FastJet algorithms. The goal is to reduce dataset size while keeping the essential information required for substructure reconstruction and analysis workflows.

nzardosh · 2026-02-24T16:58:14Z

Hi Louise, just to understand why do you use this instead of just using the JTracks table (which is also smaller)?
In any case you are of course welcome to make your own tables for studies but please move the table definitions into your task, rather than into the datamodel folder

louisemillot · 2026-02-25T18:50:24Z

Hi Nima, thanks for the clarification. I initially thought the table definitions should go into the datamodel folder, but I’ve now moved them directly into the task as suggested.
Please let me know if this looks fine!

nzardosh

Adding some more comments here. I would like to reiterate that to me trying to do embedding locally on a large scale is quite difficult and will need alot of work + alot of dedicated computing resources, so in my opinion it is not advisable. Of course it is up to you if you wish to give it a try.

nzardosh · 2026-03-02T17:01:29Z

PWGJE/TableProducer/slimTablesProducer.cxx

+  Filter particleCuts = (aod::jmcparticle::pt >= minPt && aod::jmcparticle::pt < maxPt && aod::jmcparticle::eta > minEta && aod::jmcparticle::eta < maxEta);
+
+  void processData(soa::Filtered<o2::aod::JetCollisions>::iterator const& collision,
+                   soa::Filtered<soa::Join<aod::JetTracks, aod::JTrackExtras, aod::JTrackPIs>> const& tracks)


why are you using the JTrackExtras table here?

this hasnt been resolved

I need the JTrackExtras table here because it contains the dcaZ information, without it, selectTrackDcaZ cannot access dcaZ, which is required for track selection

is there not already a dcaZ cut applied for globalTracks? Or do you need a different value?

I checked the getGlobalTrackSelection function, and indeed it already applies a dcaZ cut and a minimum number of crossed TPC rows. Since I’m also requesting these same cuts explicitly in my code, it’s technically not necessary to use JTrackExtras for these selections, except if I want to study systematics with a different dcaZ or track quality cut

nzardosh · 2026-03-02T17:04:39Z

PWGJE/TableProducer/slimTablesProducer.cxx

+
+    slimCollisions(collision.posZ());
+    auto slimCollIndex = slimCollisions.lastIndex();
+    for (const auto& track : tracks) {


are you not intending to have any track selection at all? this way you are going to take all tpc only tracks as well and many other tracks that are not good

I’m in the process of implementing a proper track selection

why do you not wish to use globalTracks?

nzardosh · 2026-03-02T17:06:51Z

PWGJE/TableProducer/slimTablesProducer.cxx

+                  slimtracks::Px,
+                  slimtracks::Py,
+                  slimtracks::Pz,
+                  slimtracks::E);


if you have pT, eta and phi then you dont need Px, Py, Pz and Energy stored explicitly like this. You can have them as dynamic coloumns.

In my case, I removed (pt, eta, phi) and kept (px, py, pz, E), since the standalone workflow relies on FastJet, which directly uses Cartesian 4-vectors as input

do you need E at detector level if you always assume the pion mass?

nzardosh · 2026-03-02T17:07:10Z

PWGJE/TableProducer/slimTablesProducer.cxx

+                  slimparticles::Phi,
+                  slimparticles::Px,
+                  slimparticles::Py,
+                  slimparticles::Pz);


since you dont assume the pion mass here why dont you save the actual energy? otherwise you cant make a proper 4 vector

I’m now saving the actual energy of the particle as well - I just forgot it

nzardosh · 2026-03-02T17:07:58Z

PWGJE/TableProducer/slimTablesProducer.cxx

+  PROCESS_SWITCH(SlimTablesProducer, processData, "process collisions and tracks for Data and MCD", false);
+
+  void processMCD(soa::Filtered<aod::JetCollisionsMCD>::iterator const& collision,
+                  soa::Join<aod::JetMcCollisions, aod::JMcCollisionPIs> const&, // join the weight


why is JMcCollisionPIs used?

this is still there

nzardosh · 2026-03-02T17:08:50Z

PWGJE/TableProducer/slimTablesProducer.cxx

+    auto slimCollIndex = slimCollisions.lastIndex();
+    slimCollisions(collision.posZ());
+    for (const auto& track : tracks) {
+      float mass = jetderiveddatautilities::mPion;


all the above comments in the data part apply here too

nzardosh · 2026-03-02T17:10:39Z

PWGJE/TableProducer/slimTablesProducer.cxx

+      float mass = jetderiveddatautilities::mPion;
+      float p = track.pt() * std::cosh(track.eta());
+      float energy = std::sqrt(p * p + mass * mass);
+      slimTracks(slimCollIndex, track.pt(), track.eta(), track.phi(), track.px(), track.py(), track.pz(), energy);


also in MC you now have a mcd table for collisions and a mcp table but there is no way to link them. How will you perform your matching between mcp and mcd?

I still dont see any matching

There is currently no MCP–MCD matching implemented in this task.
This is intentional. The goal of this workflow is only to produce reduced (slim) datasets, not to perform the embedding or matching within O2Physics.

the matching is done later in a standalone workflow:

-I build hybrid jets by combining pp MC tracks with Pb–Pb data tracks
-Then I perform the matching between these hybrid jets and the MC truth (pp) jets/particles

So the matching is done at the jet level (hybrid ↔ MC truth), not at the MCP–MCD table level inside O2
for this reason, no explicit MCP–MCD linking is implemented here

but how will you know in your framework later which particle level collision and which detector levle collision go together? I dont understand how you will match your mcd and mcp jets without this information

I’ll implement the geometric matching myself, similar to how it’s done in JE, to associate the MCP and MCD jets correctly

I think you have misunderstood me. Imagine you have 1000 detector level events where you have saved collisions and 1000 particle level events where you have saved mcCollisions. Then you run mcd jets in the detector level ones and mcp jets in the particle level ones. How do you know for a given detector level jet, which particle level event's jets you need to look at for the matching?

nzardosh · 2026-03-02T17:11:18Z

PWGJE/TableProducer/slimTablesProducer.cxx

+
+  void processMCD(soa::Filtered<aod::JetCollisionsMCD>::iterator const& collision,
+                  soa::Join<aod::JetMcCollisions, aod::JMcCollisionPIs> const&, // join the weight
+                  soa::Filtered<soa::Join<aod::JetTracks, aod::JTrackExtras, aod::JTrackPIs>> const& tracks)


why is JTrackPIs used?

vkucera · 2026-03-05T20:15:31Z

@nzardosh If you request changes before merging, please convert to draft until comments are addressed.

fjonasALICE · 2026-03-10T12:36:39Z

PWGJE/TableProducer/slimTablesProducer.cxx

+      return;
+    }
+    histos.fill(HIST("h_mcCollMCD_counts_weight"), 1.5, eventWeight);
+    auto slimCollIndex = slimCollisions.lastIndex();


I believe the ordering is wrong here. You assign slimCollIndex here to lastIndex, but then only fill the slimCollisions table in the next line. This means slimCollIndex will have the index of the previous collision, not the current one!. Same comment for processMCD

Yes, you’re right — I’ve been doing it wrong, I fixed it, thanks

nzardosh · 2026-03-12T16:14:48Z

PWGJE/TableProducer/slimTablesProducer.cxx

+    slimCollisions(collision.posZ());
+    auto slimCollIndex = slimCollisions.lastIndex();
+    for (const auto& track : tracks) {
+      if (!jetderiveddatautilities::selectTrack(track, trackSelection) && jetderiveddatautilities::selectTrackDcaZ(track, trackDcaZmax)) {


why do you use a dcaZ selection?

I added the DCAz cut to suppress secondaries and improve track quality for the jet reconstruction
Is there a specific reason why this would not be appropriate here? Otherwise I can remove it if you prefer to keep the selection minimal

globalTracks I believe already includes a dcaZ cut

nzardosh · 2026-03-12T16:15:21Z

PWGJE/TableProducer/slimTablesProducer.cxx

+  PROCESS_SWITCH(SlimTablesProducer, processData, "process collisions and tracks for Data and MCD", false);
+
+  void processMCD(soa::Filtered<aod::JetCollisionsMCD>::iterator const& collision,
+                  soa::Join<aod::JetMcCollisions, aod::JMcCollisionPIs> const&, // join the weight


this is still there

nzardosh · 2026-03-12T16:16:37Z

PWGJE/TableProducer/slimTablesProducer.cxx

+      float mass = jetderiveddatautilities::mPion;
+      float p = track.pt() * std::cosh(track.eta());
+      float energy = std::sqrt(p * p + mass * mass);
+      slimTracks(slimCollIndex, track.pt(), track.eta(), track.phi(), track.px(), track.py(), track.pz(), energy);


I still dont see any matching

nzardosh · 2026-03-19T14:05:08Z

PWGJE/TableProducer/slimTablesProducer.cxx

+  Configurable<float> minEta{"minEta", -0.9, "min eta to save"};
+  Configurable<float> maxEta{"maxEta", 0.9, "max eta to save"};
+  Configurable<float> vertexZCut{"vertexZCut", 10.0f, "Accepted z-vertex range"};
+  Configurable<float> trackDcaZmax{"trackDcaZmax", 99, "additional cut on dcaZ to PV for tracks; uniformTracks in particular don't cut on this at all"};


this configurable isnt needed anymore

adding files for slim tables for futur standalone embedding

f45018b

louisemillot requested review from alibuild, fjonasALICE, maoyx, mfasDa, mhemmer-cern, nzardosh and raymondEhlers as code owners February 23, 2026 22:07

github-actions bot added pwgje datamodel labels Feb 23, 2026

github-actions bot changed the title ~~Add SlimTables data model and producer for future standalone embedding studies~~ [PWGJE] Add SlimTables data model and producer for future standalone embedding studies Feb 23, 2026

adressing Nimas comment on declaration of tables in task

ba440d8

github-actions bot removed the datamodel label Feb 25, 2026

nzardosh reviewed Mar 2, 2026

View reviewed changes

vkucera marked this pull request as draft March 5, 2026 20:15

fjonasALICE reviewed Mar 10, 2026

View reviewed changes

louisemillot added 3 commits March 11, 2026 11:20

Add TrackSelection, adjust CollIndex

33ec927

adressing comments

a09af00

removing unnecessary columns

5f2c96a

nzardosh reviewed Mar 12, 2026

View reviewed changes

louisemillot added 2 commits March 18, 2026 16:49

removing JMcCollisionPIs table

2af7482

adressing Nimas comments

cf5b6be

nzardosh reviewed Mar 19, 2026

View reviewed changes

removing Configurable

774ebf5

Conversation

louisemillot commented Feb 23, 2026

Uh oh!

nzardosh commented Feb 24, 2026

Uh oh!

louisemillot commented Feb 25, 2026

Uh oh!

nzardosh left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vkucera commented Mar 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone